It is currently quite common for services (such as software applications, hardware devices, web services, database applications, web pages, web sites, etc.) to be monitored by a monitoring system. Monitoring systems take a wide variety of different forms, and monitor a wide variety of different things. For instance, some monitoring systems monitor the state of a service, such as whether the service is running, stopped, or has been abnormally terminated. Other monitoring systems monitor the health of services in terms of certain performance criteria. For instance, some monitors monitor the amount of memory that a service is using, or the processor capacity being used by the service, or other similar criteria.
Performing these types of monitoring of services requires knowledge of the components of a service, the dependencies of the service, and the behavior of the service. The definition of these constructs is complex, and often only comprehensible by engineers or other technical personnel who were involved in the design of the service.
Similarly, the different types of services that businesses expect to monitor are evolving in complexity, and include distributed services, as well as redundant and multi-tier architectures. These factors contribute to making the task of configuring monitoring for these types of services more and more complex.
Similarly, business applications and business solutions are currently being widely deployed. Such solutions, however, can be unique, or customized to the different users which use them. Therefore, current systems are only able to monitor such solutions by building custom monitoring logic. In order to effectively monitor a given service, a number of high-level questions must often be addressed. Examples of some of those questions (which may or may not need to be answered) are as follows:                What does the service look like?        What components is the service made of and how do the service components interact?        What infrastructure services does the service in question depend on?        How do we find the deployments of the service in a network?        How do we differentiate two deployments of the given service?        What attributes of the service are of interest to the user?        What instrumentation data should be collected about the service?        How should the data be formatted and displayed to be useful to the service administrator?        What are common tasks users perform on the service?        How does an administrator know if the service is performing as designed?        What are the issues that can affect the service's ability to function?        How can such issues be detected, or better still, prevented?        What data should be collected to diagnose the issues?        Are there any corrective actions that can be performed in response to such issues?        When should the administrator be notified of possible issues?        What data should be provided to the administrator as context to understand and troubleshoot a possible issue?        
These are just some common high level questions that may be used to guide the design of a monitoring solution for a given service. It will also be noted that each of these questions may lead to another level of detail, in which additional questions must be answered. The complexity associated with answering these questions in sufficient detail so that a monitoring system can function often surpasses the complexity that users of the solutions (or administrators of the solutions) can grasp.
Thus, companies face difficulties in obtaining adequate monitoring of their customized business solutions. The task may require it to be outsourced, which increases cost, and can be cumbersome to integrate.
The discussion above is merely provided for general background information and is not intended to be used as an aid in determining the scope of the claimed subject matter.